Content-Aware Firewalling, Policy Regulation, and Policy Management for Industrial Automation, Machine To Machine Communications, and Embedded Devices

ABSTRACT

In one embodiment, a processor-implemented method for controlling network traffic to and/or from at least one industrial machine, including: (a) receiving, as input, (i) a stored policy object in language form defining at least one desired behavior and/or operational constraint for the at least one industrial machine, and (ii) a stored machine profile defining an association between the language of the stored policy object and at least one control signal or instruction for the at least one industrial machine; (b) detecting, in network traffic to and/or from the at least one industrial machine, a transaction; (c) applying the received policy object and machine profile to the detected transaction to determine whether a desired behavior exists and/or whether an operational constraint is satisfied; and (d) modifying network traffic to and/or from the at least one industrial machine based on the determination in step (c). This permits expression and enforcement of constraints on actual industrial machine behaviors by filtering, modifying or blocking network communications (e.g., control signals and telemetry) that violate constraints or could cause unsafe or inefficient operation.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to co-pending U.S. Provisional PatentApplication Ser. No. 62/051,291, filed Sep. 16, 2014, the disclosure ofwhich is incorporated herein by reference in its entirety.

BACKGROUND

1. Technical Field

The disclosure relates, generally, to industrial automation, and moreparticularly, to policy regulation and firewalling for purposes ofcontrolling industrial machines.

2. Description of Related Art

It is possible for industrial machines to communicate with each otherusing Ethernet-based networks. These are the same networks that aregenerally used to link computers together. Traditional practice usesnetwork types other than Ethernets to network industrial machinestogether, for example DeviceNet and CAN, most notably for the purpose ofensuring that reliability and latency characteristics inherent inEthernets do not compromise the more stringent safety and efficiencyrequirements of industrial machines and automation systems.

However, in a departure from traditional practice, it is often seen thatmachines and automation devices are networked together using Ethernets,as the cost and reliability characteristics of Ethernets become morefavorable with continued development. It is also often seen thatcomputers appear networked together on the same Ethernets as industrialmachines; and that networks consisting only of computers and othernon-industrial devices are now often connected to industrial Ethernetsvia gateway devices such as switches and routers.

Indeed it is often intentional and desirable for industrial Ethernets tobe linked to computer Ethernets, and/or to contain computers themselves.The computers appearing on industrial internets may be connected ad hocor permanently to the industrial Ethernets; such computers either mayshare the connectivity of the industrial Ethernet to larger externalEthernets, or may also have independent connections to externalEthernets, in effect constituting ad hoc gateways through which trafficmay flow between the industrial Ethernets and the external Ethernets onwhich the computers appear.

The term “converged network” is used to denote an Ethernet-based networkcontaining both industrial machines and traditional computers; ornetworks containing one or the other type of device but linked to otherEthernets or WANs through switches, routers or other gateway devices.

When computers are added to industrial Ethernets, or when computernetworks are connected via gateways to industrial Ethernets, great valueis potentially created, because the computers can originate controlsignals and receive telemetry from the machines on the industrialEthernets. At the same time, tremendous vulnerabilities arise, becausethe computers and the network infrastructure devices such as switchesand routers themselves are often quite easy for attackers to compromise,and those devices are subject to malfunctions of hardware and software.Such attacks and malfunctions can create rogue control signals that canrender unsafe or inefficient the functioning of industrial machines; andthey can expose telemetry to unauthorized or malicious parties.

In addition, however, the electrical and functional characteristics ofindustrial machines are fundamentally different from those ofgeneral-purpose computers used for traditional data processingapplications. Although, strictly speaking, some industrial machinesmight include a computer, industrial machines are not general-purposecomputers that would typically be used by a human operator forapplications including such as data processing, information retrieval,email, and the like. Rather, industrial machines are specializedmachinery, apparatus, and equipment, along with associated parts,attachments, and accessories, that are used for research anddevelopment, manufacturing, and related activities, which might or mightnot embody substantial computing capability in order to implement theirspecific functionality. One example of an industrial machine is anassembly robot.

A problem very different from those of preventing undesired access toindustrial machines through Ethernets by unauthorized users or by othermachines through Ethernets, is that of inhibiting network traffic thatarrives through Ethernets and is quite normal, typical and innocuous fortraditional computers but is disruptive and even dangerous whenencountered by industrial machines. This problem does not necessarilyinvolve the presence of a malicious attacker (hence, it is not bestcharacterized as a “security” problem), but rather arises from thenatural characteristics of Ethernets themselves. Conventionally, such amode of traffic recognition and filtration is not available.

Prior art exists regarding access-control methods to address someaspects of these problems. In general, such prior art has focused on theproblem of recognizing which specific machines are being targeted withcontrol signals and from which telemetry is being requested ormonitored. Based on such recognition, access-control systems can enforcerules permitting or denying accesses from specific computers or machinesto other specific computers or machines. In particular, the large bodyof current practice classified broadly as “network firewalling” isapplicable to this aspect of the problem.

Such access-control methods are effective in preventing many kinds ofundesirable accesses to machines and computers in industrial Ethernetsthat contain networked computers or are connected to computer networks.But many problems can be created by accesses that are not prohibited byaccess-control rules. These problems are quite distinct from thosecategorized as network security problems.

Among the distinctive issues that arise specifically in Ethernets, whichinclude both traditional computer equipment and industrial machines, areproblems of policy regulation; problems arising from the differentelectrical and functional characteristics of computers and typicalindustrial machines; and problems arising as machines acquire a broaderability to communicate with one another, thus affecting the functioningof other machines. None of these problem areas has been addressed bycurrent practice or prior art.

The problem of policy regulation in converged networks arises from thegoals of controlling the behavior and function of industrial machinesfrom distant control points, and of dispatching telemetry from machinesto distant analysis points. These communications tasks are performedthrough the converged network. But the simplistic approach of simplycarrying control signals and telemetry in the native communicationslanguage of each of myriad different machines breaks down at scale.

SUMMARY

Embodiments of the disclosure provide solutions to the foregoingproblems and additional benefits, by employing a communications languagedesigned to permit the expression of the desired behavior of machinesand processes in an abstract and general form that, in turn, can beautomatically and dynamically converted to control signals pertaining tospecific machines and processes, by a communications device or devicesresident on a converged network. At the same time, the samecommunications devices can enforce conditions and thresholds (forexample, speeds, temperatures, pressures, and flow rates) beyond whichmachines and processes may not be allowed to operate for safety andefficiency reasons.

Embodiments of the disclosure provide languages and devices that permitthe expression and enforcement of constraints on actual machinebehaviors by filtering, modifying or blocking network communications(e.g., control signals and telemetry) that violate the constraints ormay otherwise cause machines to operate unsafely or inefficiently. Thisis completely different from the filtration performed by networkfirewalls, even the so-called industrial firewalls. Existing devicesfocus on permitting or denying communications based on the identity ofthe endpoints, their position within the network, and even throughanalysis of the communications protocols (for example, enforcing thatprotocols such as Modbus or Ethernet/IP are in use and syntacticallycorrect).

In one embodiment, the present disclosure provides aprocessor-implemented method for controlling network traffic to and/orfrom at least one industrial machine. The method includes: (a) theprocessor receiving, as input, (i) a stored policy object in languageform defining at least one desired behavior and/or operationalconstraint for the at least one industrial machine, and (ii) a storedmachine profile defining an association between the language of thestored policy object and at least one control signal or instruction forthe at least one industrial machine; (b) the processor detecting, innetwork traffic to and/or from the at least one industrial machine, atransaction; (c) the processor applying the received policy object andmachine profile to the detected transaction to determine whether adesired behavior exists and/or whether an operational constraint issatisfied; and (d) the processor modifying network traffic to and/orfrom the at least one industrial machine based on the determination instep (c).

In another embodiment, the present invention provides a policy-objectenforcement device for controlling network traffic to and/or from atleast one industrial machine. The device includes a processor adaptedto: (a) receive, as input, (i) a stored policy object in language formdefining at least one desired behavior and/or operational constraint forthe at least one industrial machine, and (ii) a stored machine profiledefining an association between the language of the stored policy objectand at least one control signal or instruction for the at least oneindustrial machine; (b) detect, in network traffic to and/or from the atleast one industrial machine, a transaction; (c) apply the receivedpolicy object and machine profile to the detected transaction todetermine whether a desired behavior exists and/or whether anoperational constraint is satisfied; and (d) modify network traffic toand/or from the at least one industrial machine based on thedetermination in step (c).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a converged network employing a policy regulationscheme consistent with one exemplary embodiment of the disclosure; and

FIG. 2 shows a flowchart of an exemplary process for controlling networktraffic to and/or from at least one industrial machine, in one exemplaryembodiment of the disclosure.

DETAILED DESCRIPTION

Considerable evidence exists to support the view that, in currentpractice and prior art, there is very little ability to filter specifictypes of machine behaviors in terms of the behaviors themselves—forexample, ensuring that machines will or will not perform specificfunctions or operate at particular rates, speeds, temperatures, etc. atany given time, or given the behaviors and operating characteristics ofnearby machines.

Specific machines can presently send and receive, over a network,control signals and telemetry using vendor-specific or otherwisenarrowly-defined control languages. However, embodiments of the presentinvention permit operators of machines or processes to define policyobjects, or rules governing the functions of machines and processes, inmore general terms, and enforce these more general policiesautomatically with a network device that both adapts the abstractpolicies to specific machines (according to machine-specific profiles ortranslations), and also filters the network communications to thosemachines. These general policies abstract the functioning of specificmachines, thus enabling a far more manageable and scalable approach tomanaging industrial machines, in terms of the behaviors of the machinesthemselves, and not just for protection against attackers present in theconverged network.

Another problem in converged networks arises from the radicallydifferent ways that computers and industrial machines respond to delaysor other temporal inconsistencies in network communications. Computersare designed to tolerate small delays well, whereas machines often havelittle to no tolerance for variances in latency or jitter beyondextremely narrow ranges.

Embodiments of the present invention employ a network device positionedinline with network communications in a converged network to enforcerules regarding tolerated latency or jitter, by recognizing both thetypes of devices that are communicating on the network, as well as thespecific nature of the communications itself.

These advantages extend still further when machines communicate withother machines in converged networks, to extend control signals andtelemetry which may or may not have the effect of modifying the behaviorof other machines. The problem of regulating such communications,whether they take place on a small or large scale (specifically, withinone industrial plant or location, or across multiple locations linked byEthernets or WANs), is of extreme importance in assuring safe andefficient operation.

Embodiments of the present invention permit the expression of bothfunctional commands and operational constraints on machines in anabstract language, not the ones associated with specific machines, withenough mathematical precision to permit algebraic conflict resolution,and implement the commands and constraints in a network device that hasthe ability to automatically translate and filter communications to andfrom specific machines. The goal is to target and control specificmachine behaviors through a general language which admits automatictranslation into the language of specific machines.

Embodiments of the present invention provide network firewalls thatinclude the capabilities described above.

Embodiments of the present invention employ implement the general policylanguage, together with machine-specific profiles, directly inindustrial machines (“embedding”). Such embodiments are desirablyimplemented in terms of gate-array logic, rather than traditionalsoftware running on a general-purpose processor or CPU.

One embodiment of the current invention is an automatic system that canprovide security, enforce safety and efficiency rules, and causemachines to execute arbitrary functions, in response to policy objectsexpressed in an abstract but mathematically precise language, usingdevices that are either deployed in Ethernet networks or embeddeddirectly in industrial machines.

Fundamentally, certain embodiments of the invention inspect electroniccommunications (control signals and telemetry) between and amongindustrial machines, and between and among industrial machines andtraditional computers; applying to those communications a number ofpolicy objects which are written in a mathematically-precise controllanguage that can express multiple levels of operational constraints andrequired behaviors; in some embodiments, allowing, blocking, ormodifying communications depending on the disposition of thecontrol-language analysis; in other embodiments, reporting to operatorsor automatic analysis systems the presence of communications dependingon the disposition of the control-language analysis.

An exemplary embodiment of the invention will now be described infurther detail with reference to FIG. 1, which illustrates a convergednetwork 100 employing a policy regulation scheme consistent with oneexemplary embodiment of the disclosure. Network 100 includes apolicy-object enforcement device 101 that may be deployed in acommunications network and/or embedded in a machine and is configured toimplement an abstract but mathematically-precise language for expressingdesired machine behaviors and operational constraints. Device 100 iscoupled via one or more wired and/or wireless networks 102 to aplurality of industrial machines 104 (in this example, machines of threedifferent types: Machine A, Machine B, and Machine C). Device 100 is incommunication with one or more storage devices 103 that contain one ormore software-based “profiles” 105, which convert the abstract languageinto control signals, telemetry, API calls, or other controls germane toMachines A, B, and C, respectively, to any degree of granularity.Storage devices 103 also contain “policy objects” 106 (in this example,Policy Objects A-E) created using a control language that permits thepolicy objects to have any size and complexity, thereby allowing theexpression of constraints and desired behaviors of arbitrary controls.Device 100 intercepts or otherwise inspects network communications toand from industrial machines 104 and filters, modifies, and/or blocksnetwork traffic according to the machine-specific profiles 105 and/orthe abstract rules of policy objects 106.

The control language used in this embodiment to create policy objectsthat allow the expression of constraints and desired behaviors ofarbitrary controls may have some or all of the following properties:

The control language may be constructed as a series of logicalpredicates against “controls,” which are arbitrary elements taken fromany physical domain, such as manufacturing cell zones, chemicalprocesses, electrical substations, computer networks, or eveninformation-retrieval systems.

The various controls have well-defined intrinsic properties that aredefined by the control language. These properties can represent physicalattributes such as the temperature, pressure, speed or voltage at whicha machine is operating at any given time; qualities of a data-systemtransaction such as session metadata, command words, and commandparameters; and qualities of a large scale physical process such as thenumber of automobiles being manufactured per hour in a plant.

In the control language, values for the various controls stand inlogical relationships with each other that, taken together, express anoverall set of constraints on the behavior of a large-scale system; orspecify behaviors and actions to be taken by machines under particularconditions; or both.

The control language has enough mathematical rigor to enable: 1)automatic detection of control statements which conflict with other orcannot simultaneously be true; 2) expression of conditional statementsof arbitrary complexity; 3) the maintenance of dynamic state.

In operation (when embodied in an appropriate device as describedbelow), the control language executes policy objects by evaluating thepredicates for each of the controls appearing therein, substituting foreach controlled property a value retrieved dynamically, either from areal time environment, or from a time-series of values recordedpreviously. Taken together, the logical values computed for eachpredicate appearing in the policy object produce a “disposition” whichmay serve as the input for a physical control system or reported to ananalytics-processing system, or both.

Examples of dispositions would be to permit or deny a requested controlsignal dispatched to a machine through a network; to move an actuatorarm or a conveyor belt; or to supply more or less power to an electricalgrid. It should be observed that the “granularity” of the dispositionsis arbitrary, ranging from very localized (perhaps to control thebehavior of a single machine) to the very large scale. This is aproperty arising from the nature of the controls, which may refer to anydynamically observable property, whether large-scale or small-scale.

The control dispositions of policy objects can be used as “buildingblocks,” serving as the observational input to other policy objects,possibly being carried over a communications network to effectuate sucha model across a number of different machines.

Examples of the policy objects in the control language include thefollowing:

Example A Stateful and Conditional Controls

<?xml version=“1.0”?> <p:policy-objectxmlns:p=“http://bayshorenetworks.com/policy-regulation- language/2014”policyname=“segregate-client-data” uuid=“cbdf9064-3ab711e4a2be0800276380c2”>  <p:condition label=“detect smb/cifs”control=“protocol” op=“=“ value=“smb-cifs” >  <p:condition label=“detectconfidential indicator” control=“content.regexscan” op=“~”value=“(?i)supersecret-client-A” >  <p:rule label=“set confidentialityindicator on session” verb=“set” control=“session.variable”parameter=“$confidential” value=“true” />  </p:/condition> </p:condition>  <p:condition label=“detect http” control=“protocol”op=“=“ value=“http” >  <p:condition label=“detect if confidentialityindicator is set on session” control=“session.variable”parameter=“$confidential” value=“true” >  <p:rule label=“disallow clientB website” verb=“deny” control=“http.request.host” op=“=“value=“clientb.mycompany.com” /> <p:rule label=“disallow client Cwebsite” verb=“deny” control=“http.request.host” op=“=“value=“clientc.mycompany.com” /> </p:condition>  </p:condition></p:policy-object>

This example illustrates conditionality and stateful behavior in thecontrol language, which are important characteristics of certainembodiments of the invention. It should be observed that the control“protocol” is used in two conditional statements in the language. Theseconditional statements examine the value of the “protocol” control whichis returned by the runtime environment. The additional control-languagestatements contained inside the conditionals are executed whenever theconditional statement evaluates “true.” In this example, the statementsinside the conditional labeled “detect smb/cifs” are evaluated fornetwork flows in which the protocol is determined dynamically to be SMBor CIFS (a protocol typically used to access files on file servers). Thestatements inside the conditional labeled “detect http” are evaluatedfor flows in which the protocol is determined to be HTTP.

The statement inside the “detect smb/cifs” conditional should also benoted. It evaluates the control “content.regexscan,” which logicallyapplies a regular-expression match to the contents of a file which wastransferred via the SMB or CIFS protocols. (The value “˜” given in the“op” attribute of the rule denotes a regular-expression match anywherewithin the inspected file content. Other operators are defined asappropriate.) The action of the statement is to set the value of asession variable named “$confidential” whenever content is transferredby a user that contains a match for the regular expression“(?i)supersecret-client-A”.

Next, the rules contained inside the conditional “detect http” should benoted. There is a conditional labelled “detect if confidentialityindicator is set on session,” which evaluates to true if the value ofthe session variable “$confidential” is true. This will be the case if aparticular user has previously accessed a document from a file sharecontaining text or metadata which matches “supersecret-client-A”. Inthis case, there are two rules which will be applied to that user, andthey will act to prevent her from accessing websites named“clientb.mycompany.com” and “clientc.mycompany.com”.

The scope of this policy object is important to understand. The conceptof a “session” is disclosed herein. The policy object operates on alogical transaction as detected and parsed within a set of networkcommunications. In this example, the transactions of interest areaccesses to files on file-servers; and accesses to corporate websites.It should be observed that, although the policy is applied to networkcommunications by a device located in a network, the controlledtransactions themselves are not necessarily defined with reference toany particular network locations or communication details, as isgenerally the case in devices known as “firewalls.” Rather, theboundaries of the transactions of interest are defined in the controlsthemselves.

To clarify, the example above uses the control “content.regexscan.” Thefirst of these refers to any discrete element of content (such as adocument) which is meaningfully transported over the network and visibleto the embodiment of the invention. A “regexscan” applied to thatcontent is a search for a regular expression. The rest of the rule is apredicate applied to the value returned in any particular transaction bythe regexscan operation. The predicate produces a DISPOSITION, (in thiscase either an allow or a deny, or equivalently a boolean truth-value),which then determines whether the control-language statements within theconditional will execute, within the context of that particular session.

Similar comments apply to the control “http.request.host.” This is amuch more specialized control than “content.regexscan,” in that itnarrowly denotes the Host header contained in an HTTP request. Thiscontrol therefore is only meaningful when an HTTP request is detected inthe network traffic. (Embodiments of the invention therefore parse anddetect the transactions implied by the various controls that are definedfor various applications.)

But it should be observed that the control that inspects documents hasan impact on the control that inspects HTTP requests: this takes placethrough the “session variable” named “$confidential.” The specific scopeof the session is determined, depending on application. In this case, itis useful and logical for that scope to be the set of all networkaccesses initiated by specific machines or computers, as identified byeither a network address or user-session metadata; or more generally bya vendor or machine type.

Example B Enforcing Allowed Transactions

<?xml version=“1.0”?> <p:policy-objectxmlns:p=“http://bayshorenetworks.com/policy-regulation- language/2014”policyname=“robot-control” uuid=“cbdf9064- 3ab711e4a2be0800276380c2”><p:rule label=“allowed protocol” control=“ipv4-protocol”uuid=“d84f166e560e11e3949d0800273a32bd” value=“robot-rpc” verb=“allow”op=“=“ /> <p:rule label=“allowed addresses”control=“ipv4-source-address” uuid=“056f4b583ab811e4a2be0800276380c2”value=“192.168.0.0/24” verb=“allow” op=“=“ /> <p:rule label=“allow rpccalls 100 or greater” control=“robot-rpc-txn” value=“100” op=“>=“verb=“allow” uuid=“7f521efa-3ab8-11e4-a2be-0800276380c2” /> <p:rulelabel=“allow rpc calls less than 150” control=“robot-rpc-txn”value=“150” op=“<“ verb=“allow”uuid=“887484b4-3ab8-11e4-a2be-0800276380c2” /> </p:policy-object>

In this example, the control language is being executed by a networkdevice that reads streams from a network, following the general patternof a blocking firewall. This policy object has four rules marked withthe verb “allow,” referencing three different controls. As the deviceinspects and parses the data flowing through the network, it determines(for each network flow) whether the data in the flow conform to the“robot-rpc” protocol. (Different embodiments of the invention maysupport any communications protocol(s) that are appropriate andmeaningful for their applications.) Because the verb in the rule is“allow,” any network flow that is not dynamically recognized ascomprising syntactically-correct robot-rpc data will be rejected(dropped) by the network device, which thus acts as a content-awarefirewall under the direction of the policy object.

In addition to the protocol rule, this policy object also contains arule which rejects any network traffic not originating from a source IPaddress in the network range 192.168.0.0/24. More significantly (interms of policy regulation), the next two rules reference the control“robot-rpc-txn,” a reference to transaction numbers contained in typicalRPC languages. These two rules together enforce that only RPCs withtransaction numbers in the range >=100 and <150 should be transmitted bythe network device which enforces the policy.

In this example, the “label” attributes in each policy rule are forself-documentation and logging; while the UUID numbers uniquely identifythe policy and each rule in a large-scale system in which many hundredsor thousands of similar policy objects are deployed together. The latterfeature desirably enables automatic conflict detection and (wherepossible) resolution in large-scale systems, where policy objects may bedeveloped by many different people over long periods of time.

It should be observed that the goal of a policy object like this, asapplied to controls signals electronically communicated to a robot, isto ensure safe and efficient operation of the robot.

Example C Machine Control Policy

<?xml version=“1.0”?> <p:policy-objectxmlns:p=“http://bayshorenetworks.com/policy-regulation- language/2014”policyname=“centrifuge-control” uuid=“cbdf9064-3ab711e4a2be0800276380c2”> <p:condition label=“Manufacturer Mcentrifuges” control=“centrifuge- model” op=“one-of” value=“6000series|7000 series|8000 series” >  <p:rule label=“max motor speed”control=“motor-speed” verb=“allow” op=“<“ value=“8000” />  <p:rulelabel=“report over voltage” control=“supply-voltage” verb=“report”op=“>” value=“480” /> </p:/condition> </p:policy-object>

This is an example of a policy object that illustrates operationalconstraints on machines. The conditional labeled “Manufacturer Mcentrifuges” is true whenever the control “centrifuge-model” evaluatesto one of the values “6000 series,” “7000 series,” or “8000 series.”Clearly, in this embodiment of the invention, a way of obtaining ameaningful value for this control should be obtained. It should beobserved, however, that the structure of the control language remainsuniform and consistent despite the considerable difference inabstraction levels between this example (which refers to machinecharacteristics) and that of the preceding examples (which refer tovalues obtainable by parsing network flows).

Continuing the example, it can be seen that, for Series 6000, 7000, and8000 centrifuges, a motor speed of at most 8000 RPM will be enforced.Additionally, it might be desirable to report (perhaps to a historian oranalytical database) whenever machines of this type are supplied with avoltage exceeding 480 volts.

Dynamic values for the controls “motor-speed” and “supply-voltage”should be obtained, but how to obtain those values is not necessarilyevident. Means of obtaining those values could be varied and mayinclude, e.g., using a sensor embedded in the centrifuge itself andconnected to a similarly-embedded system in one embodiment of theinvention; or a telemetry parser inside a network device; or a databaseof historical values for centrifuge motor speeds; and so forth.Embodiments of the invention distinctively provide a mechanism forincorporating the additional (“multi-layer”) controls employed to bridgethe layers of abstraction between this example of the control language,and the actual controlled values. This mechanism is disclosed below inthe section “Multilayer Policy Objects.”

An operator of centrifuges from Manufacturer M may wish to control thefunctioning of the machines, and to describe those controls in a clearand precise way. These controls are in the nature of governance andsafety rules, and in general they change only infrequently. However, thespecific models of machines subject to these controls, and the specificcontrol systems, sensors, and telemetry of the machines change far moreoften. This gap between abstraction layers is an enormous problem in thepractice of policy regulation for industrial machines and processes. Themultilayer policy objects provided by embodiments of the presentinvention bridges the gap.

Example D Firmware-Attack Prevention

<?xml version=“1.0”?> <p:policy-objectxmlns:p=“http://bayshorenetworks.com/policy-regulation- language/2014”policyname=“protect-firmware” uuid=“e5ce3198-6645-4485-baae-be80803ba3bb”> <p:condition label=“detect vendor R plc”control=“vendor-R-plc” op=“*” value=“” >  <p:rule label=“”control=“content-yarascan” verb=“deny”parameter=“malware-signatures.yara” op=“=“ value=“true” /></p:/condition> </p:policy-object>

This is an example of a policy object that protects “intelligent”electronic devices (in this case, PLCs from Manufacturer R), from beinginfiltrated with malware during a “flash” update of the firmware on thedevices. In this case, the control “vendor-R-plc” is implemented inquite a broad way, to detect any content being transferred to and fromany of Vendor R's PLCs, as determined in the network traffic. In oneembodiment of the invention, a network device that implements thispolicy may be a customized device purchased from Vendor R and containingproprietary mechanisms for detecting both the presence of that vendor'sdevices on a network; and for determining the boundaries of contenttransferred on the network to and from the devices. In other words, aproprietary network communications protocol is in use, which issupported by embodiments of the present invention through the mechanismof custom “profiles,” which specify both the syntax and the semantics ofthe network communications that may be encountered by a particularapplication, in different embodiments of the invention. It will be seenthat the construction of such protocols may be done in the same controllanguage that has been discussed above. Through itsmathematically-precise predicate structure, the control language iscapable of expressing new varieties of electronic-communications syntax(protocols), as well as new controls (semantics).

As an example, the additional control “content-yarascan” applies acollection of signatures in the Yara language, for purposes of detectingmalware. When this control is applied to the communications to and fromVendor R's PLCs, a search for malware is performed, and, if malware isfound, communication to and/or from the device is aborted.

Example E Process-Control Policy

<?xml version=“1.0”?> <p:policy-objectxmlns:p=“http://bayshorenetworks.com/policy-regulation- language/2014”policyname=“process-constraints” uuid=“7a44aa40-7a8c-4f76-ad37-6102cbc9e5cc”> <p:include label=“ethylene-controls”policy-uuid=“0d3f9a1e-3faf-4739- a94e-a2e6bdd9ff53” /> <p:includelabel=“toluene-controls” policy-uuid=“402324da-5802-4a7d-8bd3-477c6f7d8842” /> <p:condition label=“feedstock flow rate”control=“feedstock-ethylene- flow” op=“<” value=“10000” >  <p:rulelabel=“toluene production” control=“toluene-production-rate” verb=“deny”op=“>“ value=“400” /> </p:/condition> </p:policy-object>

This example captures a very high-level policy expressing a safetyconstraint in a chemical-production process. The policy states that ifethylene-feedstock flow falls below a certain range (10,000 pounds perhour), then toluene production should not be permitted to rise above 400lbs/hour.

This is an example of policy regulation in-the-large, which is enabledby the multilayer structure of the control language in embodiments ofthe invention. A number of different policy objects exist, allinspecting network communications among sensors, machines and computerswithin a chemical-production plant. Each policy object is writtenspecifically to interact with the machine-to-machine communications ofparticular devices, but the dispositions (policy outcomes; for example,allow/deny or set a state variable) are made available to policy objectsat higher levels.

In this example, the controls “feedstock-ethylene-flow” and“toluene-production-rate” are composite controls constructed from othercontrols, e.g., in the form appearing in the preceding examples. Theyare made available to the “process-constraints” policy object throughthe process of inclusion. (Note the two p:include statements, whichrefer to policy objects identified by globally-unique identifiers.)

Embodiments of the invention make this kind of policy-management in thelarge convenient and manageable, through the mechanism of abstraction atmultiple layers. It might not be practical for people at the level ofoverall plant and process management to understand the operationalcomplexities of the equipment and network architecture of a plant.Neither is it practical for people with detailed knowledge of thespecific machines and networks to have the knowledge needed to makeoverall production decisions. Yet a third knowledge, the orthogonalknowledge domain, is employed to determine safety policy for all ofthese interconnected machines and processes, quite apart from thebusiness decisions made by the plant's managers as they determine howmuch to produce and when.

Embodiments of the invention support the independent creation of policyobjects operating at each level or knowledge domain, and automaticallysynchronizes them mathematically, so that the outputs from variouspolicy objects become the inputs to policy objects at different levelsof abstraction.

In certain embodiments of the invention, an extensible control languageallows for easy extension via the definition of new controls and newdisposition types. This feature enables an overall policy-regulationframework based on this language to evolve gracefully over time, withthe addition of new capabilities and new machine types that do notdisturb the fundamental structure of existing policies or interfere withexisting controls.

In certain embodiments of the invention, a multilayer policy objectframework permits the expression and regulation of policy for operatingmachine processes at any scale, from individual devices such as robotsor pressure vessels, to complex systems such as jet engines, to entirelarge-scale systems such as the electrical grid. This quality arisesfrom the multilayer design of the control language.

To achieve its fundamental multilayer character, the control languagepermits the definition of “metacontrols” that are defined in terms ofother controls, or indeed of entire policy objects. This solves a verychallenging problem in the policy-regulation of industrial systems “inthe large,” which is the difficulty of enforcing controls and intendedbehaviors at a high level, on devices that have very detailed andmachine-specific control languages.

In certain embodiments of the invention, a processing device may be,e.g., a general-purpose computer (either virtual or hardware), or anetwork device, or an embedded device. The processing device may includecomponents such as protocol parsers and sensors to dynamically recoverthe values of controls appearing in the policy objects expressed in thecontrol language.

Embodiments of the invention may be implemented, e.g., in networkdevices, network-capture processors, and embedded devices, as will nowbe discussed in further detail.

Embodiments of the invention can be implemented as a network device,which can be a general-purpose or special-purpose computer, either in aruggedized or non-ruggedized package. In this general type ofembodiment, the invention has one or more Ethernet interfaces to permitinline operation with network communications to and from machines andcomputers; or alternatively on a network “tap,” so that it can see andanalyze copies of subsets of the traffic contained in a network. Thelanguage-based policy objects that the network device works with mayeither be configured statically into the device; or retrievedautomatically through a “management plane,” which generally is a networkconnection to a computer or computers acting as a policy repository.

In this type of implementation, embodiments of the invention can blockor modify network communications according to the dispositions producedby the policy language. For example, control signals to a machine may bedisallowed if deemed unsafe or deemed to violate business rules;and/telemetry to network endpoints deemed unauthorized or in an unsafepart of the network can be blocked.

In a second general type of implementation, embodiments of the inventioncan be supplied as software operating on captures of network traffic. Inthis case, the typical objective is to obtain forensics or otherinsights into an industrial process through analysis of historic data.

A third general type of implementation is to embed a processing device,such as a field-programmable gate array, directly into an industrialmachine. This embedded device is programmed to be able to execute thepolicy language, and to obtain (via flash updates) new policy objects.In this case, manufacturers of industrial machines can encode safety andoperational-efficiency constraints, as well as telemetry feeds, directlyinto their devices. Because of the multilayered nature of theinvention's control language, the dispositions generated by the embeddeddevice can be communicated via an Ethernet to other policy-enforcementnodes, and take part in an in-the-large policy regulation scheme.

One exemplary embodiment of the invention operates as a SCADA firewall.The SCADA firewall is a network device deployed inline with controlsignals transmitted over a network between a control application runningon a standard computer, and an industrial robot performing assembly-linefunctions. In this embodiment, the desired policy regulation is toenforce a “read-only” posture. Remote operators are prevented fromcommanding the robot to perform functions or to change itsconfiguration, but they are permitted to read diagnostic registers orother status of the robot. The network device parses the networkcommunications to and from the robot, discerns which requested functionsare “reads” and which are “writes,” and transmits the former whileinhibiting the latter.

The SCADA firewall described in connection with this embodiment analyzesthe semantics, or behavior contained within the network communications.Based on the semantic analysis which is discovered in real time by theSCADA firewall through direct analysis of the network traffic, specifictransactions requested by the control system may be allowed, rejected,or allowed with modifications by the SCADA firewall.

Another embodiment of the invention operates as a SCADA firewall, withall of the functions described above, but also incorporatesaccess-control features typically found in network firewalls. Theseadditional filtration modes enhance the value of the behavior filtrationby allowing a policy-writer to selectively permit behaviors on the basisof session metadata. For example, “writes” may never be performedagainst the robot. “Reads” may be performed only by authorized users, orfrom specific network segments, or at certain times of day.

Unlike the prior art, in embodiments of the invention, filtration basedon behavior is augmented with policy rules specifying session metadataincluding information about the users or endpoinsts, network location,environmental factors, etc. The session metadata may be discovereddynamically by the augmented SCADA firewall (by analysis of the networktraffic to and from the robot), or it may be configured statically, ordiscovered through communications on a separate management network(“control plane”).

Another embodiment of the invention operates as a policy regulator forthe so-called “Internet of Things.” In this embodiment, the invention isimplemented as a network device installed in a large-scale enterprisenetwork or in a portion of the Internet. The device has visibility totraffic to and from industrial machines or such devices as automobiles,refrigerators, handheld devices, which are connected to the networkthrough a switch, router, or gateway device. The policy regulator parsesall the network traffic that it sees, looking for specific transactions(including control signals and telemetry) to and from any or all of thenetwork-enabled machines using the network. Based on the policy objectsthat are encoded by its local administrators, the device can filter,modify, report on, or disallow any transaction that it sees.

A principal feature of embodiments of the invention is content-levelfiltration that is aware of data ranges and set points. Althoughstandard network firewall technology can filter addresses and ports, andeven has some awareness of protocols, there is no protection againstsemantic errors or attacks.

As computer usage moves from isolated network types like CAN andDeviceNet, to Ethernet, this brings integration with every other network(notably producing the “Internet of Things”), but exposes equipment to amuch broader array of potentially bad actors.

For applications relating to the “Internet of Things,” HTTP traffic maybe filtered. For industrial automation and control applications, one ormore other protocols and/or standards may be employed.

A principal feature of embodiments of the invention is a language-basedsystem for protecting transaction semantics as applied electronically tomachines or automation equipment. This can be embodied in networkdevices or embedded. This includes custom language processors fordefining new protocols (syntax) as well as new semantics.

A principal feature of embodiments of the invention is the idea of a“protective blade,” a language-based policy object that can be uploadedto a device embodying appropriate processing software or firmware.

While prior art exists around proprietary protections for machines,there is no conventional language-based protection that can be enforcedin a network device or onboard in proximity to a network connection.

In one embodiment, language processors are used for a variety ofdifferent machines and process types. These are software programscontained in the network or embedded device. Having multiple processorsfor different machines and different vendors permits a standardizationprocess that leads to global policy regulation.

In one embodiment, the language can be expressed in high-level terms andthen compiled to work against the network flows.

In different embodiments, network processors, as well as forensicprocessors (working off network captures), as well as testing anddevelopment devices that use statically generated context may beemployed.

Principal features of embodiments of the invention include: combining adynamic context (making available session data as well as content), witha policy object in language form, with a processor that applies thepolicy objects against each discrete transaction that is detected in thedynamic context and can produce a variety of dispositions.

The three principal features of embodiments of the invention discussedbriefly above will now be described in additional detail.

Policy Language

The first principal feature is the policy language, which may beconstructed from scratch or as a “schema” or instantiation of any of thevariety of existing artificial languages designed for the purpose ofcapturing predicate logic. Such artificial languages enabling theconstruction of a policy language for the current invention include XML,various languages used for constructing ontologies, or domain-specificlanguages (DSLs) constructed within general-purpose programminglanguages such as Python or Ruby.

It is not necessary that policy language itself be human-readable.Depending on implementation, the language may be a purpose-built binaryrepresentation analogous to the “bytecodes” or “machine languages” usedby virtual or hardware CPUs. In this case, some form of software toolsare desirably constructed to allow objects built in the policy languageto be viewed and edited by humans.

Controls:

The policy language is capable of expressing arbitrary assertions ofvalues of attributes, measurements, properties, or characteristics. Theitems that form the subject of value-assertions in the policy languageare called “CONTROLS” and generally represent measurable or observableproperties of machines, processes, or other aspects of the real world.

Controls may be defined to any degree of abstraction, e.g., from thevery large-scale (meteorological readings for a city; total reactivepower delivered by an electrical grid), to the medium-scale (fluid-flowrates in an oil refinery; value-at-risk in a financial-asset tradingsystem), to the very granular (temperature of a reactor vessel; IPaddresses in a network).

The policy language provides a mechanism of data-typing for eachcontrol, which may be hard-coded in particular implementations;configurable by system operators; or a combination of both. The datatype given for each control defines the range and format of the datavalues which the control may take on at various times during dynamicoperation of the invention. The data types also define semantics foreach control, including the arithmetic, logical or string operatorswhich may be applied meaningfully to dynamic values of the control, suchthat dynamic values of the control may be compared with pre-configuredranges; and such that values of different controls obeying compatiblesemantics may be compared with each other. (The latter feature enablesautomatic resolution of conflicting policy rules.)

Fundamental Data Types:

Examples of fundamental data types which may be applied to controlsinclude: ASCII-coded character strings of specified lengths; integral orfloating-point numbers of specified maximum and minimum range; andqualitative sets of mutually-exclusive attributes like color-lists.

More complex and abstract data types may also be implemented bycombining two or more of the fundamental data types; or by writingcustom software codes to reflect the characteristics of specificcontrols in particular processes or machines.

The following are two examples in XML of the definition and data-typingof controls. One relates to the outcome of HTTP (web-browser)transactions, and one relates to position data for a multi-axis roboticarm. It is noted that the data type is captured in the “comparator”field.

Example 1

<p:control name=“http.response.status”> <p:comparator>unsigned-integer-32 {100:599}</p:comparator> <p:parameter>none</p:parameter>  <p:description>  <![CDATA[  In HTTP/Sflows, this control returns the HTTP status code returned  from theback-end HTTP server. The range is a three-digit integer  between 100and 599.  This control can be used in conditional expressions to  modifyserver responses based on whether the server reported an error  or not. With non-HTTP flows, the control returns nothing.  The data type ofthis control is a 32-bit unsigned integer ranging from  100 599.  ]]> </p:description> </p:control>

Example 2

<p:control name=“robot.arm.position“> <p:comparator>ieee-754[6]</p:comparator> <p:parameter>none</p:parameter>  <p:description>  <![CDATA[   Expressthe position of a six-axis robot arm as an array of floating-  pointvalues. ]]>  </p:description> </p:control>

Predicates:

The policy language supports “PREDICATES,” which are statements of thevalues that a control may dynamically assume, expressed as booleantruth-values. The intent is to allow the computation of a truth-valuefor a given predicate at an arbitrary point in time.

The following are two examples of predicates expressed in XML:

   <p:predicate control=“http.response.status” operator=“=“   value=“200” />    <p:predicate control=“robot.arm.position”operator=“!=“ parameter=“x-axis” value=“500.0” />

As can readily be seen, the action of predicates is to expressconditions against which the dynamic or instantaneous values ofparticular controls may be meaningfully compared (with the semantics ofthe comparison being controlled by the specific data type of thecontrol), and a boolean (True/False) value may be computed. As will beseen next, this computed boolean value is used in conjunction with thecomputed values of other controls to produce an instantaneousdisposition, or policy outcome.

With reference to these examples, the value of a predicate expressedagainst a control representing an HTTP response status-code ismeaningfully determined for each occurrence of an HTTP transaction whichmay be detected in a network. The value expressing the position of theX-axis of a multi-axis robotic arm is meaningfully determined throughperiodic or event-driven automatic measurement.

The examples above show predicates expressed in terms of unchangingvalues that appear directly in the language expressing the predicate. Itmay be useful to express predicates in which the instantaneous value ofthe control is compared with the current value of other controls, orwith dynamic state values that may have been computed at some earlierpoint in time and stored in a device embodying the invention.

Logical Operations:

The policy language supports logical operations, including conjunctionand disjunction, so that the boolean truth-values computed dynamicallyfrom predicates may be combined arbitrarily to produce truth-valuesdependent on any combination of: instantaneous predicate values; storedstate; or preconfigured static data.

Dispositions and Rules:

The policy language supports DISPOSITIONS, which are the specificationsof actions to be taken upon determination of the truth-value of anyparticular predicate or logical combination of predicates. Dispositionsmay be any action at all which is relevant in the deployment context ofthe particular application.

The combination of a predicate defined against a particular control,with a disposition that is effectuated when the predicate produces alogical value of TRUE, is termed a RULE. Rules may be combined with eachother in conditional statements and other logical combinations. A set ofrules intended to be evaluated and executed together at a specific pointin time within a specific dynamic context, forms a POLICY OBJECT.

For example, a policy engine in one embodiment of the invention appliedto the control of Web (HTTP) transactions may choose to block or rewritethe contents of a transaction in which the HTTP status response-code isobserved to represent a server-error condition.

In another example, a policy engine in one embodiment of the inventionapplied to telemetry feeds from robots may choose to report anexceptional condition, possibly necessitating maintenance, to asystem-logging or event-alerting facility, when a robotic arm isobserved to be hyperextended along a particular axis (that is, the valuefor one element of an arm-position control exceeds a safe value encodedin a predicate of the policy language).

Policy Objects:

The policy language supports the creation of “POLICY OBJECTS.” A policyobject, as described above, is an ordered list of RULES (statementscomprising a predicate and a dispositions), suitable for automaticparsing (see below) and automatic execution within a dynamic environmentsuch as a network element or device, or a processor embedded within amachine.

A policy object may contain any number of predicates and dispositions.Multiple predicates within a policy object may refer to the samecontrol, in which case well-defined rules for logical combination(including conjunction, disjunction, and exclusive disjunction) areautomatically applied. Embodiments of the policy language may alsosupport automatic disambiguation for predicates that contain mutuallyexclusive values, or for predicates that, when taken together, expressconditions that violate some external condition. (An example of thelatter would express the condition that an assembly robot may not beoperated while the door to its safety cage is unlatched.)

Inclusion and Combination:

The policy language supports INCLUSION and/or COMBINATION. Inclusionoccurs when a policy object incorporates another policy object byreferring to it by name. Combination occurs when two or more policyobjects are joined together to form a composite policy object which isparsed, disambiguated, and executed as a single unified whole.

Machine Profiles and Metacontrols:

The policy language supports the creation of “MACHINE PROFILES,” whichare simply sets of controls that are relevant to specific machines,classes of machines, machine vendors, or processes. Machine profiles maycontain ordinary controls (consisting of a uniquely-defined name; adata-type; and other descriptive information); or metacontrols (seebelow); or a combination of both.

The policy language desirably contains an extensibility mechanism toallow machine profiles to be added independently of the main developmentof the policy language. This supports the expected usage pattern thatmakers of specific machines will create profiles for their own machines,which will be made available as add-ons (possibly at extra cost) tousers of embodiments of the present invention.

The particular value of the machine profile is to isolate theoperational particulars of a machine or class of machines from how themachine receives commands and sends telemetry on a network.

For example, a network-capable torque tool from a specific vendor maysend and receive data using a communications protocol such as aModbus/TCP or Ethernet/IP. A policy designed to regulate the behavior ofsuch a device may contain predicates and dispositions that controlspecific data fields within Modbus/TCP or Ethernet/IP transactions toand from the torque tool, as the transactions are observed on a network.Such transactions typically encode commands or operational measurementspertaining to the tool in specific locations within a data record (forexample, the Modbus command “Write such-and-such a numeric value toRegister 100” may have the effect of setting the torque-level for aspecific operation within the torque tool).

However, it is more preferable to express such behavioral controls interms of the commands and operational characteristics of the deviceitself, rather than in terms of how these commands and characteristicsare communicated in a network. It makes much more sense for a machinevendor or process manager to express constraints on a torque tool interms of the tool's torque level (e.g., “never exceed 10 lbs. force whenworking on a particular aircraft part”), rather than in network terms(e.g., “never allow Modbus Register 100 to be written with a valuelarger than 10.0”).

It is the purpose of a METACONTROL to encode what is in essence amapping between knowledge of a class of machine behaviors (such as theforce levels in a torque tool) and knowledge of some behaviors appearingwithin network communications. Significantly, in embodiments of theinvention, the policy language allows for the capture of such mappings.The structure of controls, predicates, and logical combinations thereofmakes such mappings straightforward. For example:

-   -   <map modbus register 100 to Vendor A torque tool force level>

In this example, the appearance of predicates referencing a control thatdenotes a torque-tool's force level will, in the dynamic executioncontext, be translated to an observation of a Modbus register value inthe actual network communications.

The METACONTROL is a distinctive and desirable feature of the policylanguage because it solves the problem of managing policy outcomes atscale, across a spectrum of object granularities. A metacontrol is acontrol whose dynamically-determined value is another control, set ofcontrols, or even an entire policy object. Predicates and dispositionscan be specified for metacontrols just as easily as they can forordinary controls.

In a dynamic execution environment, the value returned by a metacontrolmight not necessarily be observable in the immediate execution contextand may need to be retrieved from a database or from another location ina network. In this way, a “meta-policy” potentially spanning an enormousamount of cyber and process space (encompassing not just industrialplants but also cities, regions, and countries) may easily beconstructed and managed, and executed uniformly at a very large numberof network nodes within the space.

Policy-Object Processing Software

The second principal feature of embodiments of the invention is asoftware module that can parse and process policy objects written in thepolicy language, e.g., as detailed above. The purpose of the parsingsoftware is to convert, or “compile,” policy objects into a form thatmay be consumed directly by the dynamic execution context (detailed inthe next section).

The specific type of language parsing will be dictated by the choicesmade by the implementer when constructing the policy language. If acustom text-based language or bytecode is developed, then a parsingsoftware may be purpose-built, e.g., using conventional tools, suchlexical analyzers, parser generators based on context-free grammars, andthe like. If a policy language is developed as a schema in an ontologylanguage or a representational language such as XML, or as a DSL in aconventional programming language, then the implementer will have aclear choice of conventional parsing tools to use in processing thepolicy objects, generally provided as part of the ontology,representational, or programming language.

The outcome of the parsing and compilation process is the generation ofa set of commands expressed in the native language of the dynamicexecution platform, which, as noted above, may be, e.g., a conventionalcomputer, a specialized network element, or an embedded device in amachine.

The general structure of the parsed and compiled policy object reflectsthe organization of the policy language into controls, predicates,dispositions, metacontrols, inclusion and composition.

Logically, each statement in the policy language represents thecomputation of a predicate against the dynamically-observed orpre-configured value of a control. The computation results in a booleantruth value, which can be combined with other predicate truth-valuesthrough logical operators (including conjunction, disjunction, negation,and exclusive disjunction) to produce dispositions.

The processing of predicates proceeds until a final disposition isdetermined. This may involve inspecting all of the predicate statements(RULES) present in the policy object, or only a subset (if a finaldisposition can be determined without inspecting all of the rules).

The implementer of the policy language may define any number of possibledispositions. A basic set of dispositions may include, e.g.: DENY(prevent a transaction from taking place by blocking a networkcommunication or by directly controlling a machine); ALLOW (permit atransaction to take place); MODIFY (change one or more of the parametersor data elements in the transaction before passing it on in the networkor to the control system of a machine); REPORT (issue an event to ahistorian or event-logging or alerting system about some perhapsexceptional, disallowed, or unsafe combination of observed behaviors);and SET (add a data item to the retained state of the policy enforcementdevice, which can be referenced in the future processing of the compiledpolicy object).

It will be seen that the exact nature of the policy execution system (asdiscussed in futher detail below) will control the expression of thecompiled policy objects. The compiled object may be a byte code suitablefor execution by a Java Virtual Machine (JVM) or similar virtual machineimplementation; it may be conventional binary code directly executableby a CPU; or it may be calls to a programming API. In either case, itwill be observed that a device with the general characteristics of astored-program computer (von Neumann or Turing machine) should be usedto execute the compiled policy object. Embodiments of the invention maybe implemented to execute on a large variety of devices, ranging fromconventional computers; to specialized network elements such as switchesand routes; to low-power embedded devices based on gate-array logic.

Policy-Execution Engine

The third principal feature of embodiments of the invention is an enginefor executing compiled policy objects written in the policy language,and effectuating the dispositions determined dynamically by thelanguage.

Distinctive elements of the policy-execution engine are: 1) the abilityto dynamically recover values for particular controls from a dynamicruntime context; and 2) to execute dispositions meaningfully in thedynamic runtime context. It should be recalled that the action ofenforcing objects written in the policy language is to logicallyevaluate predicates against controls, and execute the resultingdispositions. Thus, the action of the policy engine, when invokedperiodically or at specific points in time within a dynamic context, isto iterate through all of the rules in order to discover whichdispositions to be executed, and then to execute one or moredispositions.

The following are three examples of implementations of a policy engine,in embodiments of the invention:

1. The Policy-Execution Engine as a Network Element

Embodiments of the invention may employ a policy-execution engineimplemented as software and deployed within a network element such as afirewall, switch, or router. The policy-execution engine may beconfigured with one or more compiled policy objects, or may retrievepolicy objects dynamically from elsewhere in the network. It is notedthat the operation of the policy-execution engine within a deployeddevice is distinct from any other functions (such as networkfirewalling) that may also be implemented on the same device.

In this example, the policy engine will actively observe, parse, andotherwise analyze the communications in the network stream in order toretrieve the instantaneous values for controls that appear inpredicates.

In this example, the policy-execution engine may be implemented“in-line,” such that it forms an essential link in the communicationsflows between machines and computers; or it may be deployed on a“network tap,” such that it can instantaneously observe network flows asthey occur. These two cases admit of different possibilities toeffectuate policy dispositions. In particular, in the “in-line” case,the policy-execution engine can selectively block or modify transactionsin real time, effectuating a policy of denying or modifying particularoperations that may violate local safety or security rules.

It is noted that, while perhaps reminiscent of the operation ofprior-art network firewalls, dispositions that block or modifytransactions are distinctly different. This is because, rather thanexecuting configuration rules that are expressed in terms of IPaddresses, ports, protocols, and other metadata, the present inventionexecutes policy rules that are expressed in terms of machine behaviorsand other high level abstractions.

2. Policy-Execution on a Discrete General-Purpose Computer

Embodiments of the invention may be implemented as software runningwithin a general purpose computer, either in a physically remotelocation from the machine environment for which it executes policy; orat a subsequent point in time. In this case, the dynamic executioncontext for the policy-execution engine may be, e.g., a stream ofdescriptions of distinct events of transactions carried in acommunications network; or entries in a database or event log containinganalogous descriptions of events.

In this case, the policy-evaluation engine is programmed to infer fromthe event data the appropriate times to invoke a policy object, and alsohow to determine the dynamic values to be used for each control. Incases where a control appearing in a policy-rule predicate has nomeaningful value or is absent altogether, that particular rule willgenerate no policy disposition.

This implementation model corresponds to the analytics systems which areof particular interest in industry. Embodiments of the invention arecapable of expressing behavioral patterns ranging from the very simpleand domain-specific, to the extremely complex and domain-agnostic. Whenexecuting such policies against archived sets of real telemetry andcontrol loop data forensically (i.e., not in real-time), the policydispositions will typically take the form of events reported to logs,historians, or database applications. This gives rise to many usefulapplications, including the prediction of machine failures or conditionsrequiring maintenance; and the easy detection of unsafe events oroperating conditions.

3. Policy-Execution on Embedded Devices

Embodiments of the invention may employ a policy-enforcement engine thatis embedded on a small, low-power computing device such as a microcontroller or system-on-chip computer, or even in FPGA logic or ASICs.Such an embedded device is constructed so as to have direct physicalaccess to the electrical and/or mechanical control mechanisms of amachine, for purposes of determining the dynamic values of controls, andfor effectuating dispositions.

Such a deployment model can be extremely efficient and cost-effectivefor purposes of protecting expensive, complex machines from the effectsof inadvertent or malicious control signals that may arrive at themachine from network connections.

In this scenario, the embedded device is connected so as to be eitherinline with or able to observe the network traffic as it arrives at themachine, and effectuate policy dispositions that may block or modify thenetwork traffic BEFORE the traffic is allowed to affect the behavior ofthe machine.

Embodiments of the invention may include large-scale implementationswith large numbers of sensors feeding data into an analytics platform,and may further include features such as secure remote access andnetwork segmentation.

FIG. 2 shows a flowchart of an exemplary process 200 for controllingnetwork traffic to and/or from at least one industrial machine, in oneexemplary embodiment of the disclosure. As shown, first, at step 201, astored policy object and stored machine profile for an industrialmachine are received. Next, at step 202, a transaction is detected innetwork traffic to and/or from the industrial machine. Next, at step203, a determination is made whether a desired behavior exists and/or anoperational constraint is satisfied, based on the received policy objectand received machine profile. If so, then at step 204, no modificationto traffic to or from the industrial machine is made, and the processproceeds to step 206. If it is determined at step 203 that the desiredbehavior does not exist and/or the operational constraint is notsatisfied, then at step 205, network traffic to and/or from theindustrial machine is modified (or blocked). Next, process 200 ends atstep 206 (and process 200 will typically be repeated multipleiterations, including for additional policy objects, machine profiles,and/or transactions).

Alternative Embodiments

It should be understood that various changes in the details, materials,and arrangements of the parts which have been described and illustratedin order to explain the nature of this invention may be made by thoseskilled in the art without departing from the scope of the invention.

The present invention can be embodied in the form of methods andapparatuses for practicing those methods. The present invention can alsobe embodied in the form of program code embodied in tangible media, suchas magnetic recording media, optical recording media, solid statememory, floppy diskettes, CD-ROMs, hard drives, or any othernon-transitory machine-readable storage medium, wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing embodiments ofthe invention. The present invention can also be embodied in the form ofprogram code, for example, stored in a non-transitory machine-readablestorage medium including being loaded into and/or executed by a machine,wherein, when the program code is loaded into and executed by a machine,such as a computer, the machine becomes an apparatus for practicingembodiments of the invention. When implemented on a general-purposeprocessor, the program code segments combine with the processor toprovide a unique device that operates analogously to specific logiccircuits.

It will be appreciated by those skilled in the art that although thefunctional components of the exemplary embodiments of the system of thepresent invention described herein may be embodied as one or moredistributed computer program processes, data structures, dictionariesand/or other stored data on one or more conventional general-purposecomputers (e.g., IBM-compatible, Apple Macintosh, and/or RISCmicroprocessor-based computers), mainframes, minicomputers, conventionaltelecommunications (e.g., modem, T1, fiber-optic line, DSL, satelliteand/or ISDN communications), memory storage means (e.g., RAM, ROM) andstorage devices (e.g., computer-readable memory, disk array, directaccess storage) networked together by conventional network hardware andsoftware (e.g., LAN/WAN network backbone systems and/or Internet), othertypes of computers and network resources may be used without departingfrom the present invention. One or more networks discussed herein may bea local area network, wide area network, internet, intranet, extranet,proprietary network, virtual private network, a TCP/IP-based network, awireless network (e.g., IEEE 802.11 or Bluetooth), an e-mail basednetwork of e-mail transmitters and receivers, a modem-based, cellular,or mobile telephonic network, an interactive telephonic networkaccessible to users by telephone, or a combination of one or more of theforegoing.

Embodiments of the invention as described herein may be implemented inone or more computers residing on a network transaction server system,and input/output access to embodiments of the invention may includeappropriate hardware and software (e.g., personal and/or mainframecomputers provisioned with Internet wide area network communicationshardware and software (e.g., CQI-based, FTP, Netscape Navigator™,Mozilla Firefox™, Microsoft Internet Explorer™, or Apple Safari™ HTMLInternet-browser software, and/or direct real-time or near-real-timeTCP/IP interfaces accessing real-time TCP/IP sockets) for permittinghuman users to send and receive data, or to allow unattended executionof various operations of embodiments of the invention, in real-timeand/or batch-type transactions. Likewise, the system of the presentinvention may include one or more remote Internet-based serversaccessible through conventional communications channels (e.g.,conventional telecommunications, broadband communications, wirelesscommunications) using conventional browser software (e.g., NetscapeNavigator™, Mozilla Firefox™, Microsoft Internet Explorer™, or AppleSafari™). Thus, the present invention may be appropriately adapted toinclude such communication functionality and Internet browsing ability.Additionally, those skilled in the art will recognize that the variouscomponents of the server system of the present invention may be remotefrom one another, and may further include appropriate communicationshardware/software and/or LAN/WAN hardware and/or software to accomplishthe functionality herein described.

Each of the functional components of the present invention may beembodied as one or more distributed computer-program processes runningon one or more conventional general purpose computers networked togetherby conventional networking hardware and software. Each of thesefunctional components may be embodied by running distributedcomputer-program processes (e.g., generated using “full-scale”relational database engines such as IBM DB2™, Microsoft SQL Server™,Sybase SQL Server™, or Oracle 10g™ database managers, and/or a JDBCinterface to link to such databases) on networked computer systems(e.g., including mainframe and/or symmetrically or massively-parallelcomputing systems such as the IBM SB2™ or HP 9000™ computer systems)including appropriate mass storage, networking, and other hardware andsoftware for permitting these functional components to achieve thestated function. These computer systems may be geographicallydistributed and connected together via appropriate wide- and local-areanetwork hardware and software. In one embodiment, data stored in thedatabase or other program data may be made accessible to the user viastandard SQL queries for analysis and reporting purposes.

Primary elements of embodiments of the invention may be server-based andmay reside on hardware supporting an operating system such as MicrosoftWindows NT/2000™ or UNIX.

Components of a system consistent with embodiments of the invention mayinclude mobile and non-mobile devices. Mobile devices that may beemployed in the present invention include personal digital assistant(PDA) style computers, e.g., as manufactured by Apple Computer, Inc. ofCupertino, Calif., or Palm, Inc., of Santa Clara, Calif., and othercomputers running the Android, Symbian, RIM Blackberry, Palm webOS, oriPhone operating systems, Windows CE™ handheld computers, or otherhandheld computers (possibly including a wireless modem), as well aswireless, cellular, or mobile telephones (including GSM phones, J2ME andWAP-enabled phones, Internet-enabled phones and data-capable smartphones), one- and two-way paging and messaging devices, laptopcomputers, etc. Other telephonic network technologies that may be usedas potential service channels in a system consistent with embodiments ofthe invention include 2.5G cellular network technologies such as GPRSand EDGE, as well as 3G technologies such as CDMA1×RTT and WCDMA2000,and 4G technologies. Although mobile devices may be used in embodimentsof the invention, non-mobile communications devices are alsocontemplated by embodiments of the invention, including personalcomputers, Internet appliances, set-top boxes, landline telephones, etc.Clients may also include a PC that supports Apple Macintosh™, MicrosoftWindows 95/98/NT/ME/CE/2000/XP/Vista/7™, a UNIX Motif workstationplatform, or other computer capable of TCP/IP or other network-basedinteraction. In one embodiment, no software other than a web browser maybe required on the client platform.

Alternatively, the aforesaid functional components may be embodied by aplurality of separate computer processes (e.g., generated via dBase™,Xbase™, MS Access™ or other “flat file” type database management systemsor products) running on IBM-type, Intel Pentium™ or RISCmicroprocessor-based personal computers networked together viaconventional networking hardware and software and including such otheradditional conventional hardware and software as may be necessary topermit these functional components to achieve the statedfunctionalities. In this alternative configuration, since such personalcomputers typically may be unable to run full-scale relational databaseengines of the types presented above, a non-relational flat file “table”(not shown) may be included in at least one of the networked personalcomputers to represent at least portions of data stored by a systemaccording to the present invention. These personal computers may run theUnix, Microsoft Windows NT/2000™ or Windows95/98/NT/ME/CE/2000/XP/Vista/7™ operating systems. The aforesaidfunctional components of a system according to the present invention mayalso include a combination of the above two configurations (e.g., bycomputer program processes running on a combination of personalcomputers, RISC systems, mainframes, symmetric or parallel computersystems, and/or other appropriate hardware and software, networkedtogether via appropriate wide- and local-area network hardware andsoftware).

A system according to embodiments of the present disclosure may also bepart of a larger system including multi-database or multi-computersystems or “warehouses” wherein other data types, processing systems(e.g., transaction, financial, administrative, statistical, dataextracting and auditing, data transmission/reception, and/or accountingsupport and service systems), and/or storage methodologies may be usedin conjunction with those of the present disclosure to achieveadditional functionality.

In one embodiment, source code may be written in an object-orientedprogramming language using relational databases. Such an embodiment mayinclude the use of programming languages such as C++ and toolsets suchas Microsoft's .Net™ framework. Other programming languages that may beused in constructing a system according to embodiments of the presentdisclosure include Java, HTML, Perl, UNIX shell scripting, assemblylanguage, Fortran, Pascal, Visual Basic, and QuickBasic. Those skilledin the art will recognize that embodiments of the present disclosure maybe implemented in hardware, software, or a combination of hardware andsoftware.

Accordingly, the terms “computer” or “system,” as used herein, should beunderstood to mean a combination of hardware and software componentsincluding at least one machine having a processor with appropriateinstructions for controlling the processor. The singular terms“computer” or “system” should also be understood to refer to multiplehardware devices acting in concert with one another, e.g., multiplepersonal computers in a network; one or more personal computers inconjunction with one or more other devices, such as a router, hub,packet-inspection appliance, or firewall; a residential gateway coupledwith a set-top box and a television; a network server coupled to a PC; amobile phone coupled to a wireless hub; and the like. The term“processor” should be construed to include multiple processors operatingin concert with one another.

It should also be appreciated from the outset that one or more of thefunctional components may alternatively be constructed out of custom,dedicated electronic hardware and/or software, without departing fromthe present disclosure. Thus, embodiments of the disclosure are intendedto cover all such alternatives, modifications, and equivalents as may beincluded within the spirit and broad scope of the disclosure.

Reference herein to “one embodiment” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment can be included in at least one embodiment of thedisclosure. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment, nor are separate or alternative embodiments necessarilymutually exclusive of other embodiments.

It should be understood that the steps of the exemplary methods setforth herein are not necessarily required to be performed in the orderdescribed, and the order of the steps of such methods should beunderstood to be merely exemplary. Likewise, additional steps may beincluded in such methods, and certain steps may be omitted or combined,in methods consistent with various embodiments of the presentdisclosure.

Although the elements in the following method claims, if any, arerecited in a particular sequence with corresponding labeling, unless theclaim recitations otherwise imply a particular sequence for implementingsome or all of those elements, those elements are not necessarilyintended to be limited to being implemented in that particular sequence.

It will be further understood that various changes in the details,materials, and arrangements of the parts which have been described andillustrated in order to explain the nature of this disclosure may bemade by those skilled in the art without departing from the scope of thedisclosure as expressed in the following claims.

The embodiments covered by the claims in this application are limited toembodiments that (1) are enabled by this specification and (2)correspond to statutory subject matter. Non-enabled embodiments andembodiments that correspond to non-statutory subject matter areexplicitly disclaimed even if they fall within the scope of the claims.

What is claimed is:
 1. A processor-implemented method for controllingnetwork traffic to and/or from at least one industrial machine, themethod comprising: (a) the processor receiving, as input, (i) a storedpolicy object in language form defining at least one desired behaviorand/or operational constraint for the at least one industrial machine,and (ii) a stored machine profile defining an association between thelanguage of the stored policy object and at least one control signal orinstruction for the at least one industrial machine; (b) the processordetecting, in network traffic to and/or from the at least one industrialmachine, a transaction; (c) the processor applying the received policyobject and machine profile to the detected transaction to determinewhether a desired behavior exists and/or whether an operationalconstraint is satisfied; and (d) the processor modifying network trafficto and/or from the at least one industrial machine based on thedetermination in step (c).
 2. A policy-object enforcement device forcontrolling network traffic to and/or from at least one industrialmachine, the device comprising: a processor, wherein the processor isadapted to: (a) receive, as input, (i) a stored policy object inlanguage form defining at least one desired behavior and/or operationalconstraint for the at least one industrial machine, and (ii) a storedmachine profile defining an association between the language of thestored policy object and at least one control signal or instruction forthe at least one industrial machine; (b) detect, in network traffic toand/or from the at least one industrial machine, a transaction; (c)apply the received policy object and machine profile to the detectedtransaction to determine whether a desired behavior exists and/orwhether an operational constraint is satisfied; and (d) modify networktraffic to and/or from the at least one industrial machine based on thedetermination in step (c).